When designing a computer-based system to implement a planning model, a question arises as to how to update the planning model. An update may be required to reflect changes to the data contained in the planning model, or the structure of the planning model, or derivations used within the planning model.
To illustrate, a spreadsheet is an example of a computer-based planning tool. A spreadsheet comprises one or more worksheets, each of which serves to organise cells into a grid consisting of rows and columns. Each cell contains alphanumeric text or a numeric value. Alternatively, each cell may contain a formula that defines how the content of that cell is to be derived from any other cell or combination of cells. If a change is made to any of the cells, the spreadsheet must be updated. Spreadsheets are frequently used as tools for handling financial information because of their ability to re-calculate themselves automatically after a change to one or more cells has been made.
Typically, spreadsheets are updated using a dependency graph. The dependency graph records (i) what other data needs to be recalculated as a result of a change, and (ii) which formula is to be used to carry out the recalculation. For example, the dependency graph records that the data in CELL A is calculated from the sum of CELL B and CELL C. So if the contents of CELL B or CELL C change, the content of CELL A must also change to reflect this.
Similarly, if the derivation of CELL A changes from the sum of CELL B and CELL C to the difference of CELL B and CELL C, the content of CELL A must also change to reflect this.
Similarly, if the derivation of CELL A changes from the sum of CELL B and CELL C to the difference of CELL B and CELL C, the content of CELL A must also change to reflect this.
This process of updating using a dependency graph is relatively simple, and it is possible to know exactly what is happening in an update cycle.
This approach is known as a cell-level approach, and the resulting dependency graph uses a node to represent each cell in the spreadsheet.
However, there is a problem when planning tools are large, for example greater than a million cells in size. Not only does cell data need to be stored, but a dependency graph having a node for each cell also needs to be calculated and stored. This results in increased overhead in the system impacting on performance and cost. This problem becomes pronounced with increasing cell count.
Alternative business planning tools exist which manage dependencies using a higher-than-cell-level approach. An example is the IBM Cognos 8 planning tool (Cognos in a registered trade mark owned by Cognos Incorporated of Canada). The IBM Cognos 8® planning tool is based on a Cube/Dimension/Link paradigm. The higher-than-cell-level approach partitions data into cubes, wherein each cube contains one or more (usually many more) cells of data. Partitioning data in cubes reduces the size of a corresponding dependency graph by reducing node count and thereby reduces overhead.
Tracking dependencies between cubes results in a smaller dependency graph but there is a potential for circularity between dependent cubes during the update cycle. Circularity occurs when a two cubes are each dependent on one another in some respect. It is important to note that at cell level, circularity need not actually exist. It is by partitioning at a higher-than-cell-level that apparent circularity is introduced. The potential for circularity in the dependency graph introduces complexity into the updating process and in some cases may require the same cube to be revisited many times during a single update cycle.
Dependencies between cells within each cube also exist and need to be handled. This results in a more complex set of dependencies which are difficult to identify and handle. In particular, there may be complex interactions between the dependencies within each cube and the interdependencies between cubes. A relatively complex updating process results, in which changes must be analysed to determine whether other dependent cubes must also be recalculated. This results in a slower updating process.
In addition to the above, the added complexity makes the partitioning methods very difficult to use in updating processes utilising multi-threaded calculation engines.
Therefore, there is a commercial need for a system which addresses the technical problems associated with the partitioning methods described above. In particular, a data partitioning system is required which results in a relatively simple, elegant and efficient updating process leading to much quicker updates.
An aim of the invention is to provide such a data partitioning system. At the very least, it is an aim of the invention to provide a system which attempts to solve one or more of the above-mentioned problems with the prior art.